With the wide application of packet data service, how to charge packet data service accurately and reasonably has become a common concern of operators.
FIG. 1 is a flowchart illustrating an activation, data transmission and de-activation of a Packet Data Protocol Context (PDP Context). As shown in FIG. 1, in General Packet Radio Service (GPRS), an implementing procedure of PDP Context activation, data transmission and de-activation includes the following steps:
Step 101: A User Equipment (UE) sends an Activate PDP Context Request to a Serving GPRS Support Node (SGSN), and this Activate PDP Context Request carries information of a Network Layer Service Access Point Identifier (NSAPI), PDP type, an Access Point Name (APN), a plurality of Quality of Service (QoS) parameters, a Transaction Identifier (TI) and so on, where NSAPI is used as a component of a Tunnel Identifier (TEID) between the SGSN and a Gateway GPRS Support Node (GGSN) to identify the PDP Context. The PDP Type includes the Peer-Peer Protocol (PPP) type, Internet Protocol (IP) type, etc. The APN may be provided for the SGSN by the UE, by which the SGSN addresses a corresponding GGSN and the GGSN determines the external network to be accessed by the UE, or the UE may choose not to provide the APN for the SGSN, in that case, the SGSN selects the default APN according to the subscriber information of the UE. The QoS parameters represent the quality required by the packet data service specified by the UE. The TI is used for the UE to identify a PDP context.
Step 102: After receiving the Activate PDP Context Request, the SGSN performs a security check and encryption with the UE, and this step is optional.
Step 103: the SGSN analyses GGSN address information according to the APN, if the SGSN finds the GGSN address information according to the APN, the TEID is created for the PDP Context. The TEID may be a combination of an International Mobile Subscriber Identity (IMSI) and the NSAPI to uniquely identify a PDP Context between SGSN and GGSN. Then the SGSN sends a Create PDP Context Request to the GGSN and the Create PDP Context Request carries PDP type, PDP address, APN, QoS parameters, TEID, and a select mode. The PDP address is an IP address of the UE, which is an optional parameter. When a Create PDP Context Request doesn't carry a PDP address therein, the IP address may be allocated by the GGSN in the subsequent process, or by a Packet Data Network (PDN) that is finally connected with the UE. The select mode refers to an APN-selecting mode, namely whether the APN is selected by the UE or by the SGSN. If the GGSN address information is not accessed for the SGSN according to the APN, the SGSN rejects the Activate PDP Context Request from the UE.
Step 104: After receiving the Create PDP Context Request, the GGSN determines an external PDN according to the APN, then allocates a Charging ID, starts charging, and confers on QoS. The GGSN sends a Create PDP Context Response back to the SGSN, when the service quality requirement is met. The Create PDP Context Response carries the information of TEID, PDP address, Backbone Bearer protocol, QoS parameters, and Charging ID. When the GGSN does not meet the service quality requirement of the QoS parameters, the GGSN rejects the Create PDP Context Request from the SGSN, and then the SGSN rejects the Activate PDP Context Request from the UE.
Step 105: After receiving the Create PDP Context Response, the SGSN adds the NSAPI and the GGSN address information into the PDP Context in order to identify this PDP Context, selects wireless precedence according to QoS parameters, and then returns an Activate PDP Context Accept to the UE. The Activate PDP Context Accept carries the information of PDP type, PDP address, TI, QoS parameters, wireless precedence, and a number of PDP configuration options. Moreover, the SGSN starts charging. The UE receives the Activate PDP Context Accept and establishes a route with the GGSN. By this time the transmission channel between the UE and the PDN is established and data transmission is able to start.
Step 106: The UE transmits data with the PDN through the SGSN and the GGSN.
Step 107: On finishing the data transmission, the UE sends a Deactivate PDP Context Request to the SGSN and the Deactivate PDP Context Request carries the TI.
Step 108: After receiving the Deactivate PDP Context Request, the SGSN performs security checks and encryption with the UE, and this step is optional.
Step 109˜Step 111: The SGSN sends a Delete PDP Context Request carrying the TEID to the GGSN. After receiving the Delete PDP Context Request, the GGSN ends the charging of the UE, deletes the PDP Context corresponding to the TEID, and then sends a to the SGSN. The Delete PDP Context Response carries the TEID. After receiving the Delete PDP Context Response, the SGSN ends the charging of the UE, deletes the PDP Context corresponding to the TEID, and then sends a Deactivate PDP Context Response carrying the TI to UE. After receiving the Deactivate PDP Context Response, the UE deletes the PDP Context corresponding to TI.
As shown in FIG. 1, in the present GRPS charging system, the charging starts when the PDP context is activated and comes to its end when the PDP context is de-activated, which means the present charging system can only charges according to a transmitted data flow or an activate time duration of the PDP context. In practice, however, after establishing a transmission channel with the PDN, the UE performs a plurality of services based on one activated PDP Context, i.e. if the PDN is able to provide a plurality of services, such as Send/Receive Email service, Wireless Application Protocol (WAP) based browse service, File Transfer Protocol (FTP) based file transfer service and so on, an activated PDP Context is able to bear various services provided by the PDN after the UE establishes a transmission channel with this PDN. Meanwhile operators or service providers may adopt different charging approaches for different charging modes of various services, for instance, Send/Receive Email service may be charged based on trigger times of Sending and Receiving events, WAP browse service may be charged according to flow, file transfer service may also be charged according to flow, and yet, a charging rate of WAP browse service is different from that of file transfer service. Thus, it is totally impossible to perform separate charging with the existing GPRS charging system for different services the same PDP Context bears.
In view of the above, it is being discussed in the 3rd Generation Partnership Project (3GPP) as to how to implement IP Flow Based Charging (FBC). As far as a packet data service is concerned, all the transmitted and received IP Flows or IP Packets when a UE user uses the service may be called Service Data Flow, i.e. the Service Data Flow is a set of a plurality of IP Flows, therefore the IP Flow Based Charging can truly reflect the resource occupation of a certain service. The IP Flow Based Charging can be described like this: IP Flows of different services that the same PDP Context bears are separately screened out through some filters similar to sieves, then the IP Flows that are screened out by different filters are separately charged so as to reach the object of separately charging different Service Data Flows. In this way, a charging granularity based on IP Flows is far less than that based on a PDP Context. The charging granularity may be regard as the size of a hole of a sieve, therefore the charging granularity based on one PDP Context will be like a sieve hole determined by one PDP Context while the charging granularity based on IP Flow will be like a sieve hole determined by one IP Flow, that is, there will be more than one sieve holes contained in one PDP Context. Therefore, comparing with the charging based on one PDP Context, charging based on IP Flow can provide more charging approaches for operators or service providers.
In 3GPP, aspects of FBC like system architectures, function requirement and flow of interactive messages are described. The FBC system architecture supporting online charging is shown in FIG. 2A, in which Online Charging System (OCS) 206 is composed of Service Control Point (SCP) 201 of Customized Application for Mobile Network Enhanced Logic (CAMEL) and a service data flow based Credit Control Function (CCF) 202. CCF 202 is connected with service data flow based Charging Rule Function (CRF) 203 through an interface Ry. The CRF 203 is connected with an Application Function (AF) 204 through an interface Rx and with the Traffic Plane Function (TPF) 205 through an interface Gx. The CCF 202 is connected with TPF 205 through an interface Gy.
The FBC system architecture supporting offline charging is shown in FIG. 2B, in which the CRF 203 is connected with the AF 204 through an interface Rx and with the TPF 205 through an interface Gx, and the TPF 205 is connected with a Charging Gateway Function (CGF) 207 and a Charging Collection Function (CCF) 208 respectively through Gz.
According to the 3GPP provision for functions implementing the FBC, the TPF 205 bears IP Flows. During and the establishment of the IP Flow bearer, the TPF 205 sends a Charging Rule Request to the CRF 203 through the Gx interface. The Charging Rule Request carries relevant information of subscriber and the UE, bearer characteristics, network information, and so on. The relevant information of subscriber and the UE may be a Mobile Station ISDN (MSISDN), an International Mobile Subscriber Identity (IMSI) and etc. In addition, the bearer may be modified during the IP Flow transmission. For example, when QoS parameters of the same service are different, charging rules may be different accordingly. For instance, the charging rate may be decrease as QoS parameters decrease. Therefore it is necessary to re-confer on QoS parameters. In this case, during the modification of the bearer, the TPF 205 resends a Charging Rule Request to the CRF 203 to request for new charging rules. The CRF 203 selects a proper charging rule according to the said input information provided by the TPF 205 and then returns the selected charging rule to the TPF 205. The charging rule includes information of charging mechanism, charging type, charging key, Service Data Flow Filter, and charging rule precedence. The charging mechanism may be online charging or offline charging. The charging type may be a type of time span based. The charging key is a parameter related with the charging rate, and the CRF 203 may provide only parameters related with the charging rate for the TPF 205, rather than directly provide the charging rate for the TPF 205. The Service Data Flow Filter is used to indicate the TPF 205 which IP Flows are to be filtered, and then the TPF 205 charges these filtered IP Flows according to the charging rules. Service Data Flow Filter may include IP quintuple having such information as Source/Destination IP Address, Source/Destination Port Number, and Protocol ID. For instance, the CRF 203 indicates the TPF 205 to filter the IP Flow with the Source IP Address 10.0.0.1, Destination IP Address 10.0.0.2, Source/Destination Port Number 20 and the protocol type Transmission Control Protocol (TCP), and then charges the filtered IP Flow according to the charging rule. Finally, during the deletion of the bearer, the TPF 205 may as well send a Charging Rule Request to the CRF 203 to request a new charging rule from the CRF. At this time, the CRF 203 may request the TPF 205 to delete the previously installed charging rule.
In addition, the CRF 203 may determine the charging rule according to the input information of the AF 204 or OCS 20 apart from the input information of the TPF 205. For example, the AF 204 may notify the CRF 203 of the current service type used by the user, and the CRF 203 may select the corresponding charging rule according to this service type.
For a GPRS network, the TPF 205 is the GGSN, the AF is a service gateway or a service server in the PDN and the CRF 203 is an added logical entity. The TPF 205 is the executing point of charging rules and the CRF 203 is the control point of charging rules.
FIG. 3A is the flow chart of issuing the charging rule when a bearer is established. As shown in FIG. 3A, the implementing procedure of issuing the charging rule when a bearer is established includes the following steps:
Step 301A: The UE sends an Establish Bearer Service Request to the TPF while in a GPRS network the corresponding process is that the GGSN receives a Create PDP Context Request.
Step 302A: After receiving the Establish Bearer Service Request, the TPF sends a Charging Rule Request to the CRF, and the Charging Rule Request carries the input information for the CRF to determine the charging rule.
Steps 303A˜304A: After receiving the Charging Rule Request, the CRF selects a charging rule according to the input information carried by the Charging Rule Request, and then returns Provision Charging Rules. The Provision Charging Rules may carry the selected charging rule.
Steps 305A˜306A: After receiving Provision Charging Rules, the TPF installs a new charging rule according to the charging rule selected by the CRF, or deletes the original charging rule, or installs a new charging rule while deleting the original one. Then the TPF receives the Establish Bearer Service Request initiated by the UE, returns an Establish Bearer Service Accept to the UE, and continues with the subsequent steps of the Establish Bearer process.
FIG. 3B is the flow chart of issuing the charging rule when a bearer is modified. As shown in FIG. 3B, the implementing procedure of issuing the charging rule when a bearer is modified includes the following steps:
Step 301B: The UE sends a Modify Bearer Service Request to the TPF while in a GPRS network the corresponding process is that the GGSN receives an Update PDP Context Request.
Step 302B: After receiving the Modify Bearer Service Request, the TPF sends a Charging Rule Request to the CRF, and the Charging Rule Request carries the input information for the CRF to determine the charging rule.
Steps 303B˜304B: After receiving the Charging Rule Request, the CRF selects a charging rule according to the input information carried by this Charging Rule Request, and then returns Provision Charging Rules carrying the selected charging rule.
Steps 305B˜306B: After receiving Provision Charging Rules, the TPF installs a new charging rule according to the charging rule selected by the CRF, or deletes the original charging rule, or installs a new charging rule while deleting the original one. Then the TPF receives the Modify Bearer Service Request initiated by UE, returns a Modify Bearer Service Accept to the UE, and continues with the subsequent steps of the Modify Bearer process.
FIG. 3C is the flow chart of issuing the charging rule when a bearer is deleted. As shown in FIG. 3B, the implementing procedure of issuing the charging rule when a bearer is deleted includes the following steps:
Step 301C: The UE sends a Remove Bearer Service Request to the TPF while in a GPRS network the corresponding process is that the GGSN receives a Delete PDP Context Request.
Step 302C: After receiving the Remove Bearer Service Request, the TPF sends a Charging Rule Request to the CRF, and the Charging Rule Request carries the input information for the CRF to determine the charging rule.
Steps 303C˜304C: After receiving the Charging Rule Request, the CRF selects a charging rule according to the input information carried by this Charging Rule Request, and then returns Provision Charging Rules carrying the selected charging rule.
Steps 305C˜306C: After receiving Provision Charging Rules, the TPF installs a new charging rule according to the charging rule selected by the CRF, or deletes the original charging rule, or installs a new charging rule while deleting the original one. Then the TPF returns a Remove Bearer Service Accept to the UE, accepts the Remove Bearer Service Request initiated by the UE and continues with the subsequent steps of the Remove Bearer process.
Besides, the CRF may also voluntarily send a charging rule to the TPF. For instance, in the data transmission process between the UE and the AF, after receiving the input information relating to charging of the AF, the CRF selects a proper charging rule according to the input information provided by the AF, and then voluntarily issues the selected charging rule to the TPF. The specific implementing procedure of the AF providing the input information of charging for the CRF is shown in FIG. 4:
Step 401: The AF sends Application/Service Data Flow Charging Information to the CRF.
Step 402: After receiving the Application/Service Data Flow Charging Information, the CRF returns an Acknowledgement (Ack) to the AF to notify the AF of already receiving the Application/Service Data Flow Charging Information sent by the AF.
FIG. 5 is the flow chart of the CRF voluntarily issuing the charging rule to the TPF. As shown in FIG. 5, the implementing procedure of the CRF voluntarily issuing the charging rule to the TPF includes the following steps:
Step 501: The CRF receives a certain Internal or External Trigger Event and relevant information about this event, such as the event of the AF sending the input information of charging rule selection to the CRF.
Step 502: The CRF selects the corresponding charging rule according to the acquired information. The acquired information may be the charging-relevant input information provided by the AF. For instance, the user is using a certain service of AF, and the service has special charging requirement, e.g., the charging rate is different from that of other services, therefore, the AF provides relevant charging information of this service for the CRF. The acquired information may also be the charging-relevant input information provided by TPF.
Step 503: The CRF sends the Provision Charging Rules to the TPF when needed, and the Provision Charging Rules may carry the selected charging rule.
Step 504: After receiving Provision Charging Rules, the TPF installs a new charging rule according to the charging rule selected by the CRF, or deletes the original charging rule, or installs a new charging rule while deleting the original one.
At present, the interactive mode concerning charging rule between the TPF and the CRF is defined in 3GPP Specification like this: The TPF sends a Charging Rule Request to the CRF when a certain trigger event is met. The trigger event may be an event of establishing, modifying or deleting the bearer. The CRF selects a proper charging rule according to the information carried in the Charging Rule Request and sends the selected charging rule to the TPF. In this way, the event trigger of the Charging Rule Request is controlled by the TPF. The event trigger of the Charging Rule Request shall be set in the TPF in advance. Whenever the event of establishing, modifying or deleting the bearer is met, the TPF sends the Charging Rule Request to the CRF. However, for some cases, the QoS parameters modified have little differences compared with original QoS parameters when the QoS parameters are modified during the modification of the bearer, and it is not necessary to modify the charging rules. In these cases, the CRF may select a charging rule similar to an original one to send to the TPF when the TPF sends the Charging Rule Request, thereby creating a great of redundant information.